IBIS Macromodel Task Group Meeting date: 14 November 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai Bob Miller Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft: Walter Katz Todd Westerhoff Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad reviewed the schedule for upcoming ATM meetings. The group decided to cancel the meetings on December 26th and January 2nd. All other meetings, including next week's, will be held as usual. ------------- Review of ARs: - Arpad to send the draft of BIRD165.1 to Mike L. for posting to the ATM archives. - Done. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Dan: Motion to approve the minutes. - Randy: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD165.1: - Discussion: Bob said he thought the posted draft looked good and was ready to submit. Radek agreed. Arpad noted that Walter had said in last week's meeting that he thought it was ready. Arpad said he would submit it to the Open Forum as BIRD165.1. No one objected. BIRD189 - File_TS0 issues. - Radek: Last week's discussion was continued in the Interconnect meeting. - Could someone summarize those discussions for those of us who didn't attend the Interconnect meeting? - Arpad: [sharing the minutes from the Interconnect meeting] - Radek: [reviewing and responding] - Mixing File_TS and File_TS0 isn't the problem. - File_TS0 itself is the problem. - I don't oppose the File_TS0 idea altogether. In its current form, I think think it's a mistake because it lets a component include a node outside the span of the nodes covered by the interconnect model. - If a draft required one of the power rails or something else to connect to ideal node 0, to expose it to the rest of the circuit being modeled, that would be okay. Otherwise we have to make it clear that there are severe restrictions on the Touchstone data if we want to ensure it's used unambiguously and correctly. - Bob: You could oppose File_TS0 entirely, or you could accept File_TS0 but acknowledge that one has to be careful when using it. The use of it is the technical concern right now. - Do you oppose it entirely? - Radek: The usage for File_TS0 is very clear, because the draft says that reference is connected to node 0. - What I'm saying is that if node 0 is not spanned by the interconnect modeling package, then it's entirely outside the modeling area. In that case there are very strict restrictions on the data in the Touchstone file. People need to be aware of the restrictions on allowable Touchstone data. - Arpad: Radek, what would you propose instead of File_TS0? - It sounds like you're unhappy with File_TS0, but how would you solve the issue it was intended to address? - What if we just found a way to do everything with a File_TS (N+1 terminals) and have the user explicitly connect the N+1st terminal to node 0? - How would that be different from File_TS0? Regardless of the File_TS or File_TS0 syntax, the user could still make a mistake and connect the rest of their model improperly. - Radek: The question is what do we want to do? - If you really want that connected to global ground, then either: - Global ground has to be present in the set of nodes spanned by the model. - or - The connection to global ground has to have no effect. - Whatever we decide must be unambiguous and correct. - I could propose removing File_TS0 altogether. - Then you have the N+1 nodes (File_TS), and the N+1st node is one of the nodes used for connections. - Regardless of what we call that global ground node, if we use it we have to make sure it's present in all the pieces of the interconnect model. - I know Arpad had suggested using A_gnd as that N+1st node, but then is that the only component that connects to A_gnd? - If this N+1st reference node can be connected to a node outside of the modeling area, then there must be no current through that node. That terminal must be internally isolated from the rest of the terminals in the component. - Let's say you have a resistor that connects nodes 1 and 2, and you have a node 3 that is isolated from the first 2. So you make a two-port model with port 1 (nodes 1 and 3) and port 2 (nodes 2 and 3). This configuration results in Z matrix non-existent, or Y matrix singular. Typical S-parameter data in a Touchstone file has no such restriction. - This is the problem. If you had some connection between nodes 1 and 3 or nodes 2 and 3 then you would get current flowing through node 3. The only case when there's no current through node 3 is the one I just described (above). If you have a configuration like that then you can freely connect node 3 to any node (including node 0). But if you don't obey this restriction then you get ambiguous results depending on what is done elsewhere in the external circuit. - Arpad: I'd like to hear a proposal to resolve this. I think we've gone over the problem statement multiple times at recent meetings. - Bob: I'm not sure it's fixable. Here's a problem: If one of the package models uses node 0 as its reference, and it's cascaded with a second package model that uses one of the traces as its reference, then you have an incompatibility. - We can just advise about this with a warning in the spec. - That second model might be an IBIS-ISS model with a node 0 reference. - Arpad: This situation reminds me of the referencing discussions related to the [Pullup Reference], [Pulldown Reference], etc. We discussed node 0 in that context too. - It sounds like Radek's concern is that if one of the interconnect models touches node 0 and nothing else in the circuit does, then you'd have a portion of the circuit disconnected from another portion. - Radek: Exactly, that's the origin of the problem. - Arpad: In IBIS, at least one of the voltage sources that supplies the I/V curve based buffer will most likely be connected to node 0. I don't know of any simulators that can do things without have the common reference somewhere. - Radek: There's a consequence of the fact that File_TS0 is forcing a connection to node 0, because you're not necessarily connecting that node 0 anywhere else in the simulation. - Arpad: Doesn't that problem exist elsewhere in the spec., too? - What if someone uses A_gnd in [External Model], couldn't you have the same argument? - I'm not sure this is the place to fix this issue. Would we have to rewrite the whole spec? - Radek: If we use the text I emailed out (included in last week's minutes), that's a clear statement to tool and model makers of the issue and restrictions. - If we say nothing we are hiding our heads in the sand. - People won't always know what they're doing if we don't give them any warning. - Originally IBIS was constructed around node 0. - [Voltage Range] was specified between global ground and the pullup_ref, for example. - We have moved on from that a bit and are now talking about PDNs and pins that are connected. We have editorial work on cleaning up the referencing issues. We've been working on that and it is not finalized. - This File_TS0 would be trying to enforce a mechanism that runs counter to these updates. - We have the same issue with an IBIS-ISS model that might include a connection to node 0 internally. - Arpad: I'm still not sure this is the place to address this. - In SPICE type simulators, if your netlist is never touching node 0 then you get a "no DC path to ground" warning. - So there's already an implicit expectation of one node somewhere being related to node 0. - Radek: You wouldn't arbitrarily take one terminal of your circuit and connect it to a totally different location and expect the results to stay the same. But we are trying to give designers a way to do it without mentioning that this could be incorrect. - Arpad: Say you have a mother board design and you're going out of your way to model all the power and ground planes. So none of your buffers is connected to node 0, they're all connected to your non-ideal planes. At some point, no matter what you do, the VRM model or some other source ends up tied back to node 0. - If that connection to node 0 already exists somewhere in the circuit, is this really an issue? - Radek: Yes, the issue is that you cannot arbitrarily grab one terminal and connect it to some outside circuitry, and that's what this is trying to do. - Only if it's known and enforced that there is no current flowing under all possible external connections, then you can freely connect it anywhere. - Bob: Radek raises the flag. - But going in the other direction, we could have everything specified relative to local references, with no node 0 declared in the modeling area ([Model], on-die interconnect, package), and Arpad is pointing out that some VRM somewhere would be hooking up the rail terminals with respect to a reference ground. But anywhere else along the path being simulated could be floating, and any place along that path where you hard code a connection to node zero could be corrupting the path. - Radek: Your scenario would be a good place not to use File_TS0. Use the File_TS and the N+1st is one of the terminals in the modeling area. - Discussion: The group discussed two different scenarios. Arpad proposed an example of a two port transmission line's S-parameter data. He said that could be the same as an ideal transformer with two independent coils connected across the two ports (2N case, independent references). He asked if you then go to common reference (N+1 case) don't you have the information needed to model the voltage relationships between port 1 and port 2? Radek said it was a mistake to assume such a model could give you the voltage information you needed without any regard for where the reference terminal were connected. Bob said he was concerned about the validity of Radek's proposed restriction text. Bob proposed a one port example in which a resistor was connected between terminal 1 and the reference terminal. He said current would indeed flow to node 0 if that were the reference terminal. Radek said this example illustrated the problem. One could not expect to connect the reference terminal to any arbitrary location without affecting the results, unless the resistor's value was infinite (reference terminal isolated from terminal 1). Radek said this situation could be modeled as a two port, with the resistor connecting terminals 1 and 2 and the third terminal a common reference and isolated from the first two. This configuration would meet the requirements of Radek's proposed restriction text. - Arpad: Can we fix this issue with a statement about something that the model maker should be aware of? I agree with Bob that whether it's node 0 or some other reference node the constraints should be the same. - Radek: My text is a precise statement of the restriction on the Touchstone data used with File_TS0. - Arpad: Thank you all for joining. AR: Arpad to submit BIRD165.1 to the Open Forum. ------------- Next meeting: 21 November 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives